%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 2: Transaction Processing System (P1, P3)}
\label{sec:iteration_2}

In the second iteration we choose to further decompose the \emph{Transaction Processing System} because the importance of this component in the overall functionality of SAB. The main drivers for this second iteration are Qas P1: "ATM and POS around Christmas" and P3: "Transaction processing". The use cases that are relevant to this iteration are:
\begin{itemize}
     \item UC7: Deposit cash
     \item UC8: Withdraw cash
     \item UC9: Issue transfer between two accounts
    \item UC11: Execute transaction
    \item UC13: Issue payment with bank card
    \item UC15: Execute direct debit
    \item UC21: Pay interests
    \item UC23: Send interbank credit instruction
    \item UC24: Receive status update from interbank credit instruction
    \item UC25: Process interbank credit instruction
\end{itemize}

The \emph{Transaction Processing System} is responsible for processing all incoming transaction commands and to send out resulting replies. To decompose this component we will take care of the incoming transaction commands from the rest of the system, processing them, and sending out resulting replies. The \emph{Transaction Processing System} is a very important part of the whole SAB system. We will make sure that transactions are processed correctly and on time and that transaction peaks can be dealt with.

To satisfy these drivers we considered different performance tactics in order to find an appropriate solution.

\begin{description}

    \item[Resource Demand:] We do not control the incoming transaction commands, no transactions can be lost and we want to process them as fast as possible. We will not use resource demand tactics.
    
        
    \item[Resource Management:] \hfill \\
        
        \vspace{-5mm} 
        \begin{description}
            \item[Introduce concurrency:] We will introduce concurrency to process multiple transaction commands at the same time and to enable scaling of the transaction processing.
            
            \item[Maintain multiple copies of either data or computations:] We will try to avoid multiple copies of data because synchronization will then become essential and give much overhead. We will use multiple copies of computations to introduce concurrency. Of course multiple copies of data can be introduced in further iterations. Multiple copies of data can be used with each specific component separately to avoid the loss of transactions.
            
            \item[Increase available resources:] The processing of transaction commands should be scalable, thus increase of resources should be supported.
        \end{description}
        
    \item[Resource Arbitration:] \hfill \\
    
    \vspace{-5mm} 
        \begin{description}
            \item[Dynamic priority scheduling:]  Deadlines will be set according to different factors (input channel, deadlines). Transaction commands will then be queued according to their deadline.
        \end{description}
        
\end{description}



% Insert figure
\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/It2_P1_P3_componentdiag.png}
    \caption{Component diagram after iteration 2}
    \label{fig:It2_P1_P3_componentdiag}
\end{figure}
    



The result of this second decomposition can be viewed in figure \ref{fig:It2_P1_P3_componentdiag}. Only the relevant components for this decomposition are shown.

In this decomposition we notice that transaction commands can be mapped to the Command Pattern and that the \emph{Transaction Processing System} acts as a Command Processor.

The \emph{Transaction Broker} component implements the Broker pattern to provide a common interface for client components so that they can easily invoke transactions to be processed. This \emph{Transaction Broker} will receive all incoming transaction commands from \emph{POS System}, \emph{ATM System}, \emph{SAB Online}, \emph{Employee Web App} and \emph{Interbank Transaction System}. It will forward the transaction commands to the \emph{Transaction Scheduler}. Each incoming transaction command will be given a deadline according to its initiator and goal.

The \emph{Transaction Scheduler} will maintain a queue of transaction commands that need to be processed according to their deadline. The \emph{Transaction Scheduler} together with the \emph{Transaction Handler} implement the Active Object pattern. The \emph{Transaction Scheduler} will also be responsible for storing delayed direct credits until they need to be executed.

%XXX: het volgende heb ik weggelaten omdat het eigenlijk alleen op de toekomst slaat. Voor het moment gaat de scheduler toch alles aankunnen.
%If this scheduler becomes a bottleneck it is possible to distribute this scheduler among different instances with separate pools of \emph{Transaction Handlers} to introduce concurrency. 

The \emph{Transaction Handler} will process the individual transaction commands separately and concurrently, these handlers can be scaled up to deal with recurrent transaction peaks. A push system can be used to process the next scheduled transaction. In this push system the scheduler will push the next transaction in the queue to the next available Transaction Handler. The \emph{Transaction Handler} will need to access the \emph{Balance Database}, which contains the balances of the bank accounts, to correctly process the transaction commands. The processed transaction commands will be logged in the \emph{Transaction Database}. The \emph{Transaction Handler} does this through the \emph{TPS Facade}. Note that a transaction command does not have to contain a debit or a credit; any instruction which requires modifying the an account balance or writing to the \emph{Transaction Database} can be encapsulated as a transaction command (cfr. Command pattern).

The \emph{Transaction Reply Router} implements the Message Router pattern. Based on the initiator and goal of the transaction command, the \emph{Transaction Reply Router} routes the resulting replies to the appropriate components. Replies can consist of e.g. error messages, confirmation messages, interbank instructions, or notifications for the Customer's inbox.

The \emph{Transaction Monitor} will monitor the throughput of the transaction commands and predict whether the processing deadline will be met by monitoring the \emph{Transaction Scheduler}. If the \emph{Transaction Monitor} detects a problem, the \emph{Operator} is notified.

Requirements can be divided over relevant components as follows:
\begin{itemize}
 
    \item \emph{Transaction Broker}
    \begin{itemize}
     \item UC7: Deposit cash
     \item UC8: Withdraw cash
     \item UC9: Issue transfer between two accounts
     \item UC13: Issue payment with bank card
     \item UC15: Execute direct debit
     \item UC21: Pay interests
     \item UC24: Receive status update from interbank credit instruction
     \item UC25: Process interbank credit instruction
    \end{itemize}
    
    
    \item \emph{Transaction Scheduler}
    \begin{itemize}
     \item P1: Transactions are handled with different priorities.
     \item P3: Transactions are scheduled based on their deadlines.
    \end{itemize}
    
    
    \item \emph{Transaction Handler}
    \begin{itemize}
     \item P1: The transaction processing infrastructure can be scaled up.
     \item P3: The transaction processing mechanism should be scalable.
     \item UC11: Execute transaction
    \end{itemize}
    
    
    \item \emph{Transaction Reply Router}
    \begin{itemize}
        \item  UC7: Deposit cash
        \item UC8: Withdraw cash
        \item UC13: Issue payment with bank card
        \item UC15: Execute direct debit
		\item UC23: Send interbank credit instruction
		\item UC25: Process interbank credit instruction
     \end{itemize}
     
     
    \item \emph{Transaction Monitor}
    \begin{itemize}
     \item P3: Transaction throughput and deadlines should be monitored.
    \end{itemize}
    
    
    \item \emph{POS System}
    \begin{itemize}
     \item UC13: Issue payment with bank card
    \end{itemize}
    
    
    \item \emph{ATM System}
    \begin{itemize}
     \item UC7: Deposit cash
     \item UC8: Withdraw cash
     \item UC9: Issue transfer between two accounts
    \end{itemize}
    
    
    \item \emph{SAB Online}
    \begin{itemize}
     \item Av2: SAB Online
     \item UC9: Issue transfer between two accounts
    \end{itemize}
    
    
    \item \emph{Employee Web App}
    \begin{itemize}
    	 \item UC7: Deposit cash
     \item UC8: Withdraw cash
     \item UC9: Issue transfer between two accounts
    \end{itemize}
    
    
    \item \emph{Interbank Transaction System}
    \begin{itemize}
     \item Av1: Interbank communication failure
     \item P2: Processing credit instructions and/or credit instruction status updates from other banks.
     \item UC23: Send interbank credit instruction
     \item UC24: Receive status update from interbank credit instruction
     \item UC25: Process interbank credit instruction
    \end{itemize}
    
    
    \item \emph{Transaction database}
    \begin{itemize}
     \item Av3: Transaction database failure
    \end{itemize}
    
\end{itemize}        
        
